Add a description of bounds encoding with implicit T bit in Appendix #99
Conversation
…dix D. No Sail yet as this change will not be adopted soon.
|
Note that #76 is more or less the same but encodes the length rather than the top. We should evaluate which works better in hardware as I can see advantages to either of them. |
|
FWIW here is some sail for the alternative version with L instead of T: 1be5cf3 . |
| Bounds decoding can then continue exactly as in \cref{sec:bounds} using $a$, $e$, $B$ and the reconstituted $T$. | ||
|
|
||
| The advantage of this encoding is that it eliminates the gap in encodings between $e=14$ and $e=24$, enabling much better bounds precision for lengths greater than about 8 MiB (see \cref{tab:caplen}) while using no extra bits. | ||
| In terms of hardware the bounds decoding is only slightly complicated by the need to compute T[8]. |
There was a problem hiding this comment.
Yes, and this bit can likely be added to the partially decompressed capability correction bits we already have in CHERIoT Ibex.
| \begin{figure}[h] | ||
| \begin{bytefield}[bitwidth=\linewidth/32]{32} | ||
| \bitheader[endianness=big]{0,8,9,16,17,21,22,24,25,31} \\ | ||
| \bitbox{1}{R} & \bitbox{6}{$p$'6} & \bitbox{3}{otype'3} & \bitbox{4}{E'5} & \bitbox{9}{T'8} & \bitbox{9}{B'9} \\ |
There was a problem hiding this comment.
I'm trying to compare this to the proposed standard: https://riscv.github.io/riscv-cheri/#section_cap_encoding
From what I can tell the exponent takes up 5 bits, the top takes up 7 bits and the base takes up 8 bits. How come we need an extra bit for both the top and the base?
There was a problem hiding this comment.
I think the compromise is a sudden drop in precision caused by the internal exponent. This means you only get byte precision up to length 511 bytes followed by 8-byte alignment, degrading in powers of two . CHERIoT has byte precision up to 511 bytes, 2-byte precision up to 1022 etc. We haven't evaluated the effect of this on software. I'd like to see table like 7.4 in CHERIoT architecture document for this encoding.
We also need to evaluate the proposed encodings in hardware.
|
I haven't followed this PR completely. I have been experimenting with the #76 PR using expanded caps in registers (in an implementation separate from Ibex (https://github.com/Cherified/Cheriot)) and it seems to have reasonable fmax (in spite of having to expand on load returns for accessing revocation bits). I will take a look at the changes you have proposed (hopefully, the bounds algorithm uses the one in #76 with top instead of length, and not the old expensive algorithm) |
As discussed in: #45
Not adding Sail to PR as needs further evaluation in HW and will not be version 1.0. Sail can be seen here: c600ec3